Conventional distributed object systems may have built-in support for the operations involved in parameter marshalling, which is the packaging of the parameters (call and return) of method calls made on remote objects. Typically, such built-in parameter marshalling is not customizable. Similarly, conventional distributed object systems may have built-in support for operations involved in parameter transporting, which is the transporting of the parameters to and/or from the remote end-point. Again, such built-in parameter transporting is typically not customizable. The two steps (e.g., parameter marshalling, parameter transporting) may be combined in conventional systems into a single entity, sometimes referred to as a channel, which is similarly not customizable. Thus, conventional systems have channels where the protocol payload format and the protocol transport are fixed, which leads to constraints and inflexibility. For example, if a distributed object system supports a first protocol via its channel, and a user of the distributed object system desires to employ a second protocol, the user may not be able to employ the second protocol due to the inflexibility of the conventional system.
In distributed object systems, a user application typically has a local representative or proxy to a remote object, where the remote object is often referred to as the server and/or server object. The distributed object system infrastructure typically intercepts method calls made on the proxy, and, in collaboration with infrastructure code delivers the call and parameters associated with the call from the proxy to the server. Similarly, results of the invocation of the call on the server are propagated by the infrastructure from the server back to the proxy, so that to the user it appears that the call executed locally.
Thus, processing involved in remoting a call made on a proxy includes serializing parameters (which may reference objects holding state on the client) associated with the method call. Such serialization is typically performed by a formatter. Serialization involves writing the state information of parameters and/or objects to a stream that may be read by a formatter on a server so that the parameters and/or objects can be recreated on the server side. Similarly, serialization involves writing the state information of return parameters and/or objects to a stream that may be read by a formatter on the client so that the return parameters and/or objects can be recreated back on the client side. Formatters also typically perform the inverse operation of deserialization. The formatters dictate the format in which the parameters and/or objects and their associated state are written to the stream. For example, a first formatter may employ a binary format while a second formatter may employ an XML format to represent the types of the parameters and/or objects and their associated state. Conventionally, formatters are not selectable, pluggable or customizable and thus conventional systems suffer from problems associated with inflexibility (e.g., inability to interact with new protocol formats).
The processing involved in remoting a call may further include securing the communication. A server may require different levels of identification (e.g., anonymous, identify, impersonate and delegate) and/or may choose different levels of payload security (e.g., integrity (signatures), privacy (encryption)). Conventionally, code associated with securing the communication was provided with the infrastructure and was not accessible, customizable, selectable and/or pluggable by a user of the infrastructure. Thus, updates to security code may have taken an unacceptably long period of time resulting in systems being vulnerable to attackers who had compromised the original security code. Thus, conventional systems suffered further from problems associated with inflexibility and inextensibility.
The processing involved in remoting a call further includes transporting the formatted, secured payload (e.g., serialized parameters and/or objects and state) between the client and the server. Different transports may be appropriate for different purposes. For example, typical transports include Hypertext Transport Protocol HTTP (e.g., for crossing firewalls), Transmission Control Protocol TCP (e.g., for intranet), Simple Mail Transport Protocol SMTP (e.g., for disconnected scenarios) and Microsoft Message Queue MSMQ (e.g., for reliable operation). Conventionally, transporting is handled by an infrastructure and such transporting is not accessible, customizable, selectable and/or pluggable by a user of the infrastructure. Thus, the infrastructure suffers even further still from inflexibility problems (e.g., inability to interact with a new transport, inability to select a most appropriate transport).
Thus, there remains a need for an architecture and/or system that mitigates inflexibility problems associated with conventional systems that are not accessible, customizable, selectable and/or pluggable.